Today's wide area networks (WAN) make extensive use of multiprotocol label switching (MPLS) networks to provide Internet services at very high rates over very broad areas. MPLS-based IP networks can efficiently route traffic and provide quality of service (QoS) control.
FIG. 1 is a prior art representation of a simplified multiprotocol label switching network. The MPLS network 100 connects a first host 110, which is a data source, and to a second host 160, which is a data destination. The first host 110 connects into the MPLS network though a first router, called label edge router (LER) 120. The second host 160 connects to a second router, called LER 170. Between the two LERs 120 and 170 are located several label switch routers (LSR) 132, 134, 136 and 138. Only the LERs 120 and 170 are used to connect the MPLS network to external hosts. Connections may exist between any label edge and LSRs, though in general, connections between routers within the MPLS network 100 are installed in accordance with good practices based on geographical location of each router, need for providing sufficient capacity and reliability between the routers, etc.
When the first host 110 intends to send a packet towards the second host 160, it includes in that packet an IP header comprising a source IP address of the first host 110 and a destination address of the second host 160. The packet including the IP header is forwarded to the LER 120. The LER 120 forwards the packet towards one of the LSRs based on traditional IP forwarding methods. In addition, the LER 120 adds a label request in the packet. For example, the LER 120 sends the packet to the LSR 132. In response to the label request, the LSR 132 allocates a label for use between the LER 120 and the LSR 132, and stores that label in an internal table for later use. The LSR 132 forwards the packet, for example towards the LSR 134, the packet still including the label request. The LSR 134 in turn allocates another label for use between the LSR 132 and the LSR 134. The process is repeated at each router until the packet reaches the LER 170 on a unidirectional, forward path. At that time, labels have been allocated for each link between two routers and each allocating router has stored label values internal tables. The LER 170 removes the label request and forwards the packet to its destination, that is, towards the host 160. At the same time, the LER 170 informs one of the LSRs, that is, the LSR which was immediately before the LER 170 on the forward path, of the label the LER 170 has allocated to a link between it and that LSR. That LSR takes note of the label value allocated by the LER 170, and forwards the packet towards a next router, informing that next router of the label value it has itself allocated. The process continues towards the LER 120. As such, as this label information towards the LER 120, each router along the forward path is informed of labels used between itself and the next router on the forward path. A collection of labels between routers along a data path is called a Label Switched Path (LSP). As new packets are sent from the first host 110 and the second host 160, the LER 120 that receives those packets directly from the first host 110 adds a relevant label value to the packets, wherein the relevant label value relates to traffic to be exchanged between these two hosts and to the next router on the LSP towards the other host. That next router does not need to look at any destination address included in those packets as it rather forwards the packet based on the label only. As a result, not only all packets exchanged between the two hosts travel through a same LSP, but the routers act more rapidly in receiving and forwarding the packets based on those labels, not having to route the packets based on IP addresses. It should be noted that an LSP is unidirectional, so an identical process of setting a second LSP is required, in a reverse direction from the LER 170 connected to the second host 160 towards the LER 120, connected to the first host 110.
A tutorial entitled “Multiprotocol Label Switching (MPLS)” is available from the International Engineering Consortium. This tutorial is included herein by reference.
Generalized MPLS (GMPLS) extends MPLS beyond the IP routing domain into other areas such as time division multiplexing, optical networks, and the like. GMPLS uses a suite of protocols, including open shortest path first (OSPF), resource reservation protocol (RSVP) and link management protocol (LMP). OSPF finds the topology of a network and provides information on the property of ports within the network, this information comprising for example data rate capacity of such ports. RSVP, once a path has been computed by use of OSPF, reserves the resources. LMP distributes information e.g. on link failures. One of the improvements added within GMPLS is the possibility for a router to suggest a label value when opening a path, rather than simply requesting a label value from the next router in on the path. The router that receives the label request comprising the suggested label value may optionally accept the suggestion, or decline it and supply another label value. Ideally, the suggested label value is accepted, as this accelerates the process of setting up switching configuration within the routers. The suggested label value may be declined if the router that receives it detects that the value is in conflict with another label already in use.
A tutorial entitled “Generalized Multiprotocol Label Switching (GMPLS)” is available from the International Engineering Consortium. This tutorial is included herein by reference.
One important disadvantage of MPLS is that this technology requires important capital and operational investments. These networks require sophisticated levels of configuration and expensive hardware. As a result, there is a drive towards using Ethernet as a base for providing high quality and high rate services at lower costs. However, Ethernet is not, traditionally, well suited to traffic engineering and QoS control. Provider backbone bridge-traffic engineering (PBB-TE), specified in Institute of Electrical and Electronics Engineers (IEEE) specification number 802.1Qay, is a recent technology based on Ethernet, which aims at providing similar advantages as those offered by MPLS networks, at lower costs. PBB-TE, sometimes also called provider backbone transport (PBT), works at layer two in a manner similar to MPLS at the IP layer.
GMPLS added to PBB-TE enables automation of the PBB-TE configuration. A path computation engine, defined in GMPLS, uses information obtained by use of OSPF, to know the network topology within the PBB-TE network.
FIG. 2 is a prior art representation of a simplified provider backbone bridge-traffic engineering network. To those skilled in the art, a strong parallel is evident between FIGS. 1 and 2. In contrast with the MPLS network of FIG. 1, the PBB-TE network of FIG. 2 comprises bridges, not routers, and switches traffic at layer two.
The PBB-TE network 200 connects a first customer premise 210, which is a data source, and to a second customer premise 260, which is a data destination. The first customer premise 210 connects into the PBB-TE network through a first bridge, called backbone edge bridge (BEB) 220. The second customer premise 260 connects to a second bridge, illustrated as BEB 270. Between the two BEBs 220 and 270 are located several backbone core bridges (BCB) 232, 234, 236 and 238. Only the BEBs 220 and 270 are used to connect the PBB-TE network to customer premises. Connections may exist between any BEBs and BCBs.
FIGS. 3 and 4 are prior art representations of a backbone edge bridge and of a backbone core bridge, respectively. The BEB 300 comprises a customer instance component 310, sometimes called I (for ‘Instance’) component, and a backbone component 350, sometimes called B (for ‘Backbone’) component. The BCB 400 only comprises a B component. Both the I and the B components comprise external ports, and a switching relay, each B component also comprises the above mentioned forwarding database (FDB). The I component of the BEB 300 comprises a plurality of customer instance ports (CIP), for connection towards customer premises. The B component of the BEB 300 comprises a plurality of provider backbone ports (PBP) for connection towards other bridges of the PBB-TE network. The B component of the BCB 400 has a single type of ports, the provider network port (PNP). In the BEB 300, the I and B components are linked by connections between provider instance ports (PIP) of the I component and customer backbone ports (CBP) of the B components.
Returning to FIG. 2, when the first customer premise 210 intends to send a packet towards the second customer premise 260, it first sends the packet to the nearest, or first, BEB 220. Configuration information in the first BEB 220 indicates that the second customer premise 260 is served by the second BEB 270. Part of the configuration information present at the first BEB 220 comprises a layer two address of an input/output (I/O) port of the second BEB 270 for serving the second customer premise 260. The first BEB 220 initiates creation of a tunnel, or switched path, by sending the packet towards the second BEB 270. The packet now comprises, as a destination address, the layer two address of the I/O port of the second BEB 270, a layer two source address designating an I/O port of the first BEB 220, a tag designating the customer site 210 where the packet was originated, and a virtual location area network (VLAN) identifier, in addition to the original packet content. Each BCB along the path receives the packet. On FIG. 2, an exemplary path is shown with links 240a, 240b, 240c, 240d and 240e, noting that links 240a and 240e are not, properly speaking, part of the PBB-TE network. In this example, BCBs 232 and 238 are part of the path. A forwarding database (FDB) in those BCBs 232 and 238 considers the destination address and VLAN identifier to determine an I/O port of the BCB on which the packet shall be forwarded towards its destination. When the OSPF and RSVP processes are executed, the FDBs of each BCB have all stored the layer two destination address and the VLAN identifier. Thereafter, as new packets come in, the BEBs and BCBs forward those packets based on the layer two destination address and on the VLAN identifier stored in FDBs along the path. In essence, the VLAN identifier acts as a label for the path.
It is essential that a combination of the VLAN identifier and layer two address of the second (receiving) BEB 270 is unique within the PBB-TE network, in order for switching based thereon to be functional. It may happen that, in the exemplary PBB-TE network of FIG. 2, the second BEB 270 receives the first packet and discovers that the VLAN identifier cannot be accepted because its value is already in use, for the layer two address of a receiving port. In such a case, negotiation must be made between the two BEBs to select a different VLAN identifier. Evidently, this delays the set-up of the path between the two BEBs.
In US 2007/0086455, Allan et al. attempt to solve this problem. A path request is sent from a bridge on an originating side. The path request arrives at a bridge on a terminating side. The terminating side bridge allocates a VLAN identifier and passes it towards the originating side on an RSVP message. While their method may avoid collision between VLAN identifier values, it may extend the time required to set-up a path, at the beginning of a session. Their method also requires extensive configuration in all BEBs.